ci: dispatch the status update as the daemonless-dispatch App - #81

Summary

Every image build ends by dispatching status-update to daemonless-io. That dispatch used DISPATCH_TOKEN, a personal PAT readable by all 149 image repos through secrets: inherit, so every docs deploy run was attributed to a person.

 notify-status
+  create-github-app-token (daemonless-dispatch, repositories: daemonless-io)
   Trigger status update
-    curl -H "Authorization: token $DISPATCH_TOKEN" .../daemonless-io/dispatches
+    gh api .../daemonless-io/dispatches  (GH_TOKEN = App installation token)

daemonless-dispatch is a new App installed on daemonless-io only, with contents write. Its id and key are the org secrets DISPATCH_APP_ID / DISPATCH_APP_PRIVATE_KEY (already set). A leaked key can trigger a docs deploy and nothing else.

Callers use this workflow at @main, so no DBUILD_REF bump is needed.

Evidence

• Before: gh api repos/daemonless/daemonless-io/actions/runs?event=repository_dispatch → actor.login = ahze on every run.
  After: a dispatch sent with a token minted from the App's key: run 43106121671, actor.login = daemonless-dispatch[bot]. (That run was later cancelled by the deploy workflow's pages concurrency queue when two image builds dispatched behind it, which is the normal coalescing behavior.)

Merge Danger

Door: two-way. Revert restores the PAT path; DISPATCH_TOKEN stays in place until the first real build's notify-status job is confirmed, then gets deleted.

Blast Radius: notify-status

Runs on every image build on main. If the secrets or the installation were wrong, that one job fails and the build itself is unaffected (needs do not depend on it).